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SUMMARY 

A Real-Time Multiprocessor Simulator (RTMPS) has been developed at NASA 
Lewis Research Center. The RTMPS uses parallel microprocessors to achieve 
computing speeds needed for real-time engine simulation. This report describes 
the use of the RTMPS system to simulate a small turboshaft engine. The process 
of programming the engine equations and distributing them over one, two, and 
four processors Is discussed. Steady-state and transient results from the 
RTMPS simulation are compared with results from a main-frame-based simulation. 
Processor execution times and the associated execution time savings for the two 
and four processor cases are presented using actual data obtained from the 
RTMPS system. Included Is a discussion of why the minimum achievable calcula- 
tion time for the turboshaft engine model was attained using four processors. 
Finally, future enhancements to the RTMPS system are discussed Including the 
development of a generalized partitioning algorithm to automatically distribute 
the system equations among the processors In optimum fashion. 


INTRODUCTION 

Modern jet engines and their controls continue to become more and more 
complex. Over the years, engine designs have continued to Increase thrust-to- 
welght ratios. To gain this Increased efficiency, the engines must operate 
closer to surge conditions - conditions which can lead to catastrophic engine 
stalls. Therefore, digital electronic engine controls are being developed that 
provide close monitoring of engine parameters and precise control of fuel flow 
and variable geometry. 

Using a real-time simulation of an engine can facilitate the development 
of these digital controls because It allows the actual control hardware and 
software to be tested In a realistic fashion. If the real-time simulation Is 
Implemented on a digital computer, the time required by the computer to com- 
plete one pass through the equations representing the engine must not be 
greater than the Integration step size. However, because of the massive amount 
of calculation required to model a complex engine, real-time simulation of 
modern jet engines on a single processor requires a fast, dedicated main-frame 
computer or simplification of the engine model. 

A Real-Time Multiprocessor Simulator (RTMPS) has been developed at NASA 
Lewis Research Center to demonstrate the potential of using parallel micro- 
processors for real-time engine simulation (refs. 1 and 2). In addition to the 
RTMPS hardware, a structured, macro-based Real-Time Multiprocessor Language 
(RTMPL) (refs. 3 and 4) and a Real-Time Multiprocessor Operating System 
(RTMPOS) (refs. 5 and 6) were developed to form an RTMPS programming environ- 
ment. The RTMPL software allows engineering-level personnel to develop slmu- 
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1 at 1 on programs for the RTMPS. The operating system allows the user to 
Interactively communicate with the RTMPS system 

This report describes the use of the RTMPS system to simulate a small tur- 
boshaft engine. The turboshaft simulation represents the first real applica- 
tion of the RTMPS system. Therefore, the paper presents an evaluation of the 
RTMPS from a user's point of view. 

Key features of the RTMPL and RTMPOS and their use to develop the turbo- 
shaft engine simulation are discussed and demonstrated. The process of pro- 
gramming the engine equations In RTMPL and distributing the RTMPL equations 
over one, two, and four processors Is also discussed. Steady-state and tran- 
sient results from the RTMPS simulation, obtained using the RTMPOS, are com- 
pared with results from a mainframe-based simulation. Processor execution 
times and the associated speed-up for the two and four processor cases are 
presented using actual data obtained from the RTMPS system. Included Is a 
discussion of how the minimum achievable calculation time for the turboshaft 
engine model was attained using four processors. Finally, planned enhancements 
to the RTMPS system are discussed Including the development of a generalized 
partitioning algorithm to automatically distribute the system equations among 
the processors In optimum fashion. 


THE REAL-TIME MULTIPROCESSOR SIMULATOR HARDWARE CONFIGURATION 

A schematic of the RTMPS hardware Is shown In figure 1. The RTMPS consists 
of 2(n+l ) processors (l.e., 16-bit, single-board microcomputers) 2n shared 
memories (l.e., dual-port memory boards) connected via two data busses. Two 
processors are reserved and the remaining 2n processors are available to oper- 
ate on portions of the simulation. One reserved processor, designated the 
Front End Processor (FEP), Is the communication link between the user and the 
simulation. The FEP allows the simulation to run Interactively. The user may 
monitor the results coming from a simulation while It Is running and may also 
make changes to key simulation parameters "on-the-fly" while a transient Is 
being run. The other reserved processor, designated the Real-Time Extension 
(RTX), Is the communication link between the simulator and external devices 
such as actuators or controllers. The FEP and the computational (COMP) proc- 
essors, are linked through the Interactive Information Bus. The RTX and the 
remaining processors, called preprocessors (PREP), are linked through the Real- 
Time Information Bus. In general, both the COMP and PREP processors can be 
used for solving the simulation equations. For Interactive simulation, only 
the Real-Time Information Bus Is used to transfer real-time data between the 
processors. This Is because the Interactive Information Bus may be busy 
servicing user requests. 

In each simulation channel, the COMP and PREP processors communicate 
through the shared memory. If data are to be transferred between two COMP 
processors, the data must be sent from the first COMP processor, through shared 
memory, to Its corresponding PREP processor, across the Real-Time Information 
Bus to the PREP processor of the channel to receive the data, then finally 
through that channel's shared memory to the COMP processor requiring the 
Information. Because of this round-about path, transfers of data between COMP 
processors are avoided when formulating an RTMPS simulation. 
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THE REAL-TIME MULTIPROCESSOR LANGUAGE (RTMPL) 

RTMPL la a structured, high-order language designed to facilitate the 
development of error-free, time-efficient simulations In a digital multiproc- 
essor environment (refs. 3 and 4). It Is a macro-based language which offers 
the advantage that any simulation written In the language Is Independent of the 
processors on which It Is to be executed. Simulation source code executed on 
one set of processors need not be changed to be able to execute on another set 
of processors. Only the macro-based language operations need be retargeted for 
the new machine. An RTMPL language utility (translator) has been developed 
that converts the RTMPL source code to a list of macro calls. 

An assembly language programmer performs a one-time systems task to develop 
the optimum assembly code for the language operation macros. The execution of 
the simulation Is only as efficient as the pre-programmed macros. 

For each processor ( 1 . e . , program) In the simulation, the user specifies 
each constant and variable used In the program and their data type, precision, 
scale factor, and value, as appropriate. The language utility keeps track of 
the constants and variables associated with each processor, which values must 
be sent from one processor to another, when a current value of each has been 
calculated so that data transfer can begin, and when all processors have 
completed the calculations assigned to them. 

A small turboshaft engine simulation will be used later to further 
Illustrate features of RTMPL. 


THE REAL-TIME MULTIPROCESSOR OPERATING SYSTEM (RTMPOS) 

RTMPOS provides the user with a versatile, Interactive means for control- 
ling and obtaining results from a simulation executing on the RTMPS. RTMPOS 
resides on the Front-End-Processor (FEP) and serves as the Interface between 
the user and the simulator. It allows him to load, run, debug, and obtain 
and/or monitor results from the simulation. The user may also use RTMPOS to 
modify and specify the computational flow of the simulation while It Is 
executing. 

The RTMPL translator produces "data base" files that contain Information 
needed for that Interactive execution of the simulation. The RTMPOS uses the 
data base Information at run-time to allow the user to Interactively execute 
the simulation. RTMPOS also allows the data base to be edited; that Is, it 
allows changing/displaying values of constants and Initial conditions on var- 
iables at run time. This modified data base may then be saved on disk, If 

desired, and any portion or all of It may be listed on a printer. 

At run time the program control features of RTMPOS are used to load the 
program modules from the disk files Into the desired simulation channels and 
to activate the execution of each of the program modules. Just as with an 
analog or hybrid computer, three modes of program execution are available 
through RTMPOS. They are: RUN, HOLD, and STOP. In the RUN mode all programs 

are activated on the simulator and they run repeated update cycles of the 

simulation until the user Issues a STOP command or the simulator Issues a halt 

advisory. (A halt advisory results from an error condition In the simulator 
and terminates the simulation execution.) In the HOLD mode, user specified 
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variables In any or all program modules are held at current or preselected 
values for a specified number of update cycles as requested by the user. In 
the STOP mode, simulation execution Is suspended and the simulator Is halted. 

A very useful feature of the RTHPOS Is the creation of a permanent session 
history disk file. This file saves all user commands, prompts, and messages 
from the operating system during a user session on the simulator. Hence, the 
entire session Is self-documenting and the user can review the sequence of work 
performed In the session. Successive session histories document the complete 
development and debug process during the buildup of a complex simulation so the 
user has a record of each step In the simulation development process. Further- 
more, the commands In a session history file can be automatically read and 
executed by RTMPOS, allowing the user to quickly return to a condition obtained 
In a previous session. 

Selected simulation parameters may also be sampled as a function of time 
during any transient run of a simulation. These data are saved In a disk file 
and they may be listed In tabular form or they may be transferred to a graphics 
utility where they may be plotted to display functional relationships In visual 
form. 

Features of RTMPOS will be further Illustrated using a simulation of the 
small turboshaft engine model discussed In the next section. 


THE SMALL TURBOSHAFT ENGINE MODEL 

The process of testing and debugging the Real-Time Multiprocessor Simulator 
(RTMPS) hardware and system software required the selection of a suitable 
dynamic simulation model. It was decided to use an available aircraft engine 
model. That model was felt to be representative of modern air-breathing 
engines, yet simple enough to allow concentrating on the RTMPS system hardware 
and software to be debugged. Simulating a more complex engine model would 
hinder efficient debugging of the RTMPS hardware and software. 

Selected was a model of a small turboshaft engine In the 20 000 lb thrust 
class. Included In the model are mathematical representations of the follow- 
ing: a slngle-centrlfugal-stage, five-axial-stage compressor that Includes 

variable Inlet guide vanes and variable stator vanes for the first two stages; 
an annular combustor; a two-stage, axial, air-cooled gas generator turbine 
that drives the compressor rotor; compressor exit bleed air that cools the 
turbine; a second two-stage turbine that Is uncooled and that has a coaxial 
drive shaft that extends forward through the gas generator turbine and connects 
to the engine output shaft. 

A digital computer simulation of the small turboshaft engine model had been 
developed previously on a central, mainframe computer. The simulation had been 
thoroughly debugged and was operational. In addition, a large base of data 
from the simulation was on file. This Information could be used to verify 
results coming from the RTMPS. 

As will be shown later, this small turboshaft engine model turned out to 
be nearly Ideal for verifying RTMPS operation. It was of sufficient complexity 
to offer a challenging partitioning problem for the processors. In the process 
of determining what equations should go on the various processors, much Insight 
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was gained and generic partitioning algorithms were developed. Since the tur- 
boshaft engine model only had six dynamic state variables, the simulation of 
this engine model did not produce long execution times and bog down the check- 
out of the RTMPS system. 

For the purpose of checking out the RTMPS, results coming from the main- 
frame simulation of the small turboshaft engine model were used as the standard 
against which the RTMPS results would be judged. 


RESULTS AND DISCUSSION 

In the process of checking out the RTMPS hardware and software, three RTMPS 
simulations of the small turboshaft engine were developed: a single-processor 

simulation, a dual-processor simulation, and a quad-processor simulation. The 
purpose of the single-processor simulation was to check the basic hardware and 
software functions and to develop a data base of results from the RTMPS to be 
used as a basis for further checkout of the system. The dual-processor simu- 
lation exercised some of the Interface software and hardware Including the 
ability of a computational processor and a preprocessor to exchange Information 
through a shared memory In a timely and effective fashion. The quad-processor 
simulation further exercised the Interface software/hardware system and demon- 
strated the effectiveness of the dual-bus, parallel-processing concept. The 
objective was to show that the RTMPS, together with the RTMPL high-order multi- 
processor language and RTMPOS user operating system, provided an effective and 
efficient environment for real-time simulation. 


The Single-Processor Simulation 

One of the first steps In developing an RTMPL simulation Is the definition 
of constants and variables. RTMPL Is a structured language and, as such, 
requires that all constants and variables used In the simulation be thoroughly 
defined. The language allows no numeric constants to be used In the simulation 
equations. Hence, each constant must be assigned an alphanumeric name In the 
constant definition section of the program. A portion of the constant defini- 
tions for the turboshaft engine model Is shown In figure 2. 

The definition section begins with the declaration CONSTANT. Following 
this declaration Is a list of the constants used In the program. Notice that, 
for each constant, Its name Is Immediately followed by Its type and precision. 
The type may be either Integer (I) or scaled fraction (S). Integers are count- 
ing numbers and do not have a decimal point. Scaled fractions are fixed point 
numbers with an absolute value less than one. The precision Is specified by 
either 1, 2, or 3 with 1 signifying single precision and 2 and 3 specifying 
double and triple precision, respectively. Scaled fractions require a further 
specification, namely, a scale factor. Because the scaled fraction Is limited 
to values between -1 and +1, a scaled fraction Is obtained by dividing the raw 
data value by some appropriate constant value called the scale factor. RTMPL 
requires that the scale factor be a power of 2. So for a scaled fraction, 
after the data type and precision, In the definition declaration. Is a slash 
(/) followed by the exponent of the power of 2 scale factor. Integers are not 
scaled, so no scale factor exponent appears In their definition. Finally, 
within brackets appears the value of the constant. If a data table Is being 
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defined, the number of values making up the table Is followed by brackets 
holding the table values. 

The definition for variables In the program follows basically the same 
format. A portion of the variable definitions for the small turboshaft simu- 
lation Is shown In figure 3. The definition section begins with the declara- 
tion VARIABLE. Following this declaration Is a list of the variables used In 
the program. For each variable, Its name Is Immediately followed by Its type. 
Its precision, and Its scale factor exponent, If the variable Is a scaled 
fraction. This Is exactly the same as was done for the definition of the pro- 
gram constants. Within brackets for variables, however, are not only the var- 
iable Initial condition value, but also what Is designated as a hold value. 

This Is the value that the variable will be set to by the RTMPOS If the vari- 
able Is chosen to be "held fixed" or "frozen" under the RTMPOS HOLD mode of 
program execution. In figure 3, the slash (/) within the brackets signifies 
that the number following Is both the Initial condition value and the hold 
value for that variable. (A separate hold value for the variable would be 
specified by a number preceding the slash.) 

The equations defining the small turboshaft engine model for this simula- 
tion are contained In an executive section, a portion of which Is shown In 
figure 4. This section begins with the declaration EXEC, followed by the 
executive name. Following this declaration Is the collection of equations 
making up the simulation. The operators used In these equations are defined 
RTMPL operations and the program appearing In the executive section will not 
change, no matter what computer system It Is to be executed on. What will 
change are the system macros which translate each RTMPL operation used In the 
simulation Into corresponding assembly code. RTMPL translates the EXEC code, 
as Input by the user, Into assembly language source code corresponding to the 
computer system to be used to execute the program. In addition to the assembly 
language code, RTMPL automatically creates extensive documentation for the 
user. Included In the documentation are references giving the relative loca- 
tion of each constant and variable used In the program. The assembly language 
source code file can then be assembled and linked to obtain an object file of 
the program which can be executed on the target computer system. A file con- 
taining the complete assembly code listing of the program to be executed Is 
created In the process. This file can be printed out to obtain a hard copy 
record of the contents of each memory location used by the program. 

The small turboshaft engine simulation was executed on the single processor 
RTMPS at four typical steady-state operating conditions. Steady-state results 
agreed very well with the steady-state results from the mainframe simulation 
standard at the corresponding operating conditions. Typical results. are shown 
In table I where selected values at one of the steady-state conditions are 
shown for the two simulations. The RTMPS results agree with the mainframe 
standard to within 0.2 percent. These small errors occur mainly because the 
RTMPS simulation uses scaled fraction arithmetic whereas the mainframe simula- 
tion uses floating-point arithmetic. Also, the RTMPS simulation Is run on a 
Motorola Exormacs development system based on the M68000 microprocessor chip 
with 16-bit memory. The mainframe computer was an IBM 370 with 32-bit memory. 

Because of the excellent match between steady-state results from the RTMPS 
and the mainframe standard. It was felt that the RTMPS hardware and software 
were operating correctly. Also, RTMPL was proving Itself to be an extremely 
effective, high-order language. A careful examination of the program code 
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revealed that It was producing assembly code that was 99 percent as efficient 
as code produced by an experienced assembly language programmer. RTMPOS also 
was proving Itself to be a valuable tool. RTMPOS properly loaded the simula- 
tion Into the RTMPS, and allowed the user to monitor key parameters as the 
simulation was achieving steady-state conditions. 

A “stale data" error occurs when data from different calculation cycles are 
mixed - for example, when a parameter value not corresponding to the current 
calculation cycle Is used to update parameters In the current cycle. Subtle 
differences caused by these kinds of errors can mistakenly be attributed to 
roundoff. To flag these, and other errors, If they existed. In comparing 
single, dual, and quad-processor simulation results, engineering unit conver- 
sions of the RTMPS memory contents were purposely printed In their entirety 
using the RTMPOS. Printed In their entirety, corresponding engineering unit 
conversions were expected to match exactly. The automatic unsealing of simu- 
lation parameters by the RTMPOS was an extremely welcome feature of the oper- 
ating system. The RTMPOS further allowed the user to change operating 
conditions easily, and created a session history file In which to store the 
results . 

To examine the dynamic characteristics of the single-processor RTMPS simu- 
lation and to check the data sampling and related features of the RTMPOS, a 
40 sec transient was executed, starting at one of the four selected steady- 
state conditions. The first 2 sec was a steadying out period, allowing the 
simulation to reach a true steady-state condition. Then, during the next 
7 sec, engine fuel flow was ramped from Its design value to a value of 0.784 
of design, which was held for an additional 18 sec. This was to allow the 
transient response to settle out so that the simulation could again approach a 
steady-state condition. Engine fuel flow was then ramped back up to Its design 
value over the next 4 sec and that value was held for the remaining 9 sec of 
the transient. 

Figure 5 shows a graph of engine fuel flow versus time. Figures 6 to 8 
show the corresponding time responses of gas generator turbine speed, compres- 
sor discharge temperature, and gas generator turbine Inlet pressure, respec- 
tively. The agreement shown In figures 6 to 8 Is representative of the 
agreement found for other parameters In the simulation. The RTMPS transient 
results agreed with the mainframe transient results to within 0.5 percent. 


The Dual-Processor Simulation 

As shown In the last section, the RTMPS single-processor results were In 
excellent agreement with corresponding output from the mainframe standard. 

This demonstrated the validity of the RTMPS single-processor simulation and 
provided a basis for checking multiprocessor simulations of the small turbo- 
shaft engine on the RTMPS. 

When using a multiprocessing system, the simulation and Its results should 
remain unchanged; only the effective calculation time should be decreased. 
Hence, If the single-processor equations are distributed among two or more 
processors, the output data from the resulting simulation should agree exactly 
with corresponding output from the single-processor simulation. Without exact 
agreement, the system hardware and/or software would be judged to be not work- 
ing properly. 
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To partition the simulation equations for solution on a multiprocessor 
system, one must consider the execution times for each equation In the simula- 
tion. The execution time for each equation In the single-processor RTMPS 
simulation was obtained by summing estimated execution times for each operation 
required to solve the equation. Hence, each equation then had an execution 
time associated with It. Given this timing Information, the small turboshaft 
engine simulation equations could be divided to run on multiple processors 
thereby reducing the effective calculation time. The following criteria were 
used to evaluate various partitioning schemes: 1) the time to complete the 

calculations on each processor should be closely balanced; 2) processor use 
should be maximized; that Is, Idle time waiting for data from other processors 
should be kept to a minimum; and 3) the number of data transfers between 
processors should also be kept to a minimum. 

For the dual-processor case, the simulation equations were split as shown 
In figure 9. The resulting calculation times for the processors were within a 
few clock cycles of being equal. Neither processor wasted time waiting for 
data from the other. And only nine transfers of data between processors were 
required. 

The nine data transfers between processors exercised the shared memory 
between processors. When this simulation was first run on the dual-processor 
RTMPS with the same transient used for the single-processor simulation, the 
results did not agree with those coming from the single-processor simulation. 
Several system software bugs and a timing flag error were discovered and cor- 
rected before exact duplication of the single-processor results was achieved. 
Without the capability of printing the engineering unit conversions In their 
entirety, determining whether the two simulations agreed exactly would have 
been a very time consuming task. It would have required accessing memory and 
examining Its hexadecimal contents to make sure that the simulation results 
were the same. The operating system's ability to automatically convert these 
hexadecimal numbers to very accurate equivalent engineering units allowed this 
effort to be readily accomplished. It proved to be a particularly useful tool 
In tracing the almost negligible differences between corresponding single and 
dual-processor simulation outputs occurring mldtranslent. The criterion for 
exact duplication of results, and being satisfied with nothing less, sparked a 
long, persistent effort which led to the discovery and correction of the subtle 
timing flag problem. 

A portion of the steady-state output from the single and dual-processor 
simulations Is shown In table II. The corresponding results matched exactly. 
Figures 10 to 12 show comparisons of time transients of gas generator turbine 
speed, compressor discharge temperature, and gas generator turbine Inlet pres- 
sure, respectively, for the single and dual-processor simulations. The cor- 
responding transients were exact duplicates for the two simulations. 

Satisfied that the hardware and software were working for this dual- 
processor case, further partitioning and distribution of the small engine 
simulation equations could be pursued with confidence. 


The Quad-Processor Simulation 

To partition the simulation equations for the quad-processor RTMPS, It was 
useful to compute "can start" and "can end" times for each equation In the 
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single-processor simulation. The earliest that the calculation of an equation 
"can start" Is that time at which the calculation of every parameter to the 
right of the equal sign has been completed. The earliest the calculation of 
an equation "can end" Is Its "can start" time plus Its execution time. Equa- 
tions with only constants or state variables (outputs of Integrators) to the 
right of the equal sign "can start" at time zero. In turn, subsequent equa- 
tions (which depend on results from previous equations) "can start" at the 
latest "can end" time of the parameters to the right of the equal sign. For 
any simulation this Information can be obtained using this purely mechanical 
method. For the small turboshaft engine simulation, the Information Is shown 
In figure 13. 

The equation string culminating with the equation with the latest "can end" 
time was placed on a processor by Itself. The other equations were divided 
among three other processors In a way such that the total execution time of 
none of the three exceeded that of the first. The resulting distribution of 
the equations among the four processors Is shown In figure 14. Results 
obtained with the quad-processor RTMPS matched exactly with the single and 
dual-processor results. Time transients of gas generator turbine speed, com- 
pressor discharge temperature, and gas generator turbine Inlet pressure are 
shown In figures 15 to 17, respectively. The transients shown In these figures 
are exact duplicates of the corresponding single and dual-processor transients 
shown In figures 10 to 12. A portion of the steady-state output for the 
single, dual, and quad-processor simulations Is shown In table III. The 
steady-state data were Identical. Results were not affected by running the 
simulation on one processor, two processors, or four. Only the effective 
calculation time was affected. 


Effective Calculation Time 

As was alluded to In the Introduction section of this report, the reason 
for developing a multiprocessor simulator Is to take advantage of any paral- 
lelism In the simulation model for the purpose of decreasing the effective 
calculation time. The single-processor simulation required 3.83 msec to com- 
plete one pass through all the calculations. The dual-processor simulation 
required 2.26 msec and the quad-processor simulation required 1.81 msec. 

Thus, the dual-processor configuration executed the small turboshaft engine 
simulation 1.7 times faster than did the single-processor configuration. 
Ideally, all else being equal, one could expect two processors to complete a 
given set of calculations twice as fast as If only one processor were avail- 
able. Practically, this Is not true. Some time Is lost In multiprocessor 
overhead, primarily because of data transfer requirements between processors. 
Data calculated on one processor and needed by another requires that the RTMPS 
transfer that data over the Real-Time Information Bus and/or through shared 
memory. These transfer operations add to the effective calculation time. 

Also, the simulation equations may not partition equally between the two proc- 
essors. The effective calculation time will be dictated by the "critical path" 
time. This latter effect will be discussed In the next section. 

The data transfer time among processors Is even more pronounced In the 
quad-processor configuration. Ideally, four processors would complete a set 
of calculations four times faster than only one processor. But for the RTMPS, 
four processors execute the small turboshaft simulation 2.1 times as fast as 
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the single-processor configuration. The "critical path" execution time, which 
Is 1.81 ms, Is the dominant factor, as will be discussed In the next section. 

The RTMPS multiprocessor system used for this study had relatively slow 
16-bit processors by today's standards. Using, newer 32-bit microcomputer 
boards will Increase the processing speed by a factor of four or five. But 
the existing system did demonstrate the effective time savings that can be 
realized by taking advantage of parallelism present In a simulation model. 


Partitioning and Effective Time Savings Limits 

The "critical path" of a simulation consists of the serial string of cal- 
culations which requires the longest execution time. For the quad-processor 
simulation of the small turboshaft engine model, the "critical path" resided 
on processor B In figure 14. The last variable calculated on that processor, 
NG, had the longest "can end" time as discussed In the Dual Processor Simula- 
tion section. Also, for each equation, the variable appearing to the left of 
the equal sign was required as an argument In the following equation. On an 
equation basis, the equation set residing on processor B could not be distrib- 
uted further among processors so as to be made to execute faster. If any of 
the other three processors In the quad-processor simulation had a longer exe- 
cution time than processor B, using additional processors to take advantage of 
any further parallelism In the simulation model would have an effect on the 
effective calculation time. This Is so because the "critical path" execution 
time Is the minimum time within which the simulation can be executed. In the 
case of the small turboshaft engine model, though, this was not the situation. 

Timing studies showed that using four processors to simulate the small 
turboshaft engine model yielded an effective speed up of 2.1 over using only a 
single processor. As previously stated, this was the fastest that the turbo- 
shaft engine model could be run on the RTMPS system using equation level par- 
titioning. Using more processors would have no further effect at reducing the 
calculation time since the "critical path" of the simulation model was already 
on one processor by Itself, and the execution time of no other processor was 
greater than this one. 

Partitioning of simulation equations Involves a number of straight forward 
tasks. However, they are rather time consuming to carry out by hand, as was 
done for this study. To automate these tasks, development of a general parti- 
tioning .algorithm has been undertaken at the Lewis Research Center. The par- 
titioning algorithm will use timing Information from the RTMPL translator to 
determine "can start" and "can end" times for each equation and will distribute 
the equations among the available processors In optimum fashion. Details will 
be presented In a forthcoming NASA report. 


CONCLUDING REMARKS 

A small turboshaft engine has been modeled and simulated on the real-time 
multiprocessor digital simulator (RTMPS), developed at NASA Lewis. A general 
purpose, macro-based, high-order, multiprocessor language, RTMPL, was used to 
program the RTMPS. An Interactive multiprocessor operating system, RTMPOS, was 
used to load the simulation programs and to control the operation of the RTMPS. 
The RTMPS hardware and the RTMPL and RTMPOS software had previously been 
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developed at NASA Lewis. The RTMPS hardware and software proved to be useful, 
reliable tools for simulation. 

The results of this study demonstrated that the RTMPS can take advantage 
of parallelism In a simulation model and significantly reduce the effective 
calculation time for the simulation. This result Indicates that a digital 
multiprocessor simulator such as the RTMPS can be a viable alternative to large 
mainframe digital and analog/hybrid computers for achieving real-time simula- 
tion of complex dynamic systems. In the current study, Involving a turboshaft 
engine model, an effective time savings factor of 2.1 was realized. Four 
processors were used simultaneously to evaluate the simulation equations. 

Other dynamic system models, containing more parallelism In the equations, 
would benefit from using additional processors and would experience a greater 
speedup. Partitioning at a level lower than the equation level (at the opera- 
tion level, for Instance) might also Improve performance. The use of state-of- 
the-art processors and busses Is expected to result In simulators that can 
provide real-time simulation speed for a wide range of simulation applications. 
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TABLE I. - COMPARISON OF SINGLE-PROCESSOR AND MAIN-FRAME 
COMPUTER STEADY-STATE RESULTS 


SINGLE 

PROCESSOR 

MAINFRAME 

NG = 

= 41522, 

NG 

= 41516. 

NP = 

== 21194, 

NP 

- 21163. 

PT'l ’ 

= 173.18 

P41 

<= 173. IT 

P45 ’ 

= 37.133 

P45 

~ 37.116 

T3 • 

= 1164.0 

T3 

» 1164.1 

WS3 ’ 

-• .16321 

WS3 

* .16314 


TABLE II. - COMPARISON OF SINGLE-PROCESSOR AND DUAL-PROCESSOR 
STEADY-STATE RESULTS 


SINGLE PROCESSOR RESULTS 


STSE1CH2 . C » DHQTH4 ( LV ) 
STSE 1 CIT2 , C . DHQTH5 ( LV ) 
STSE1CH2.C.DH41 (LV) = 
STSE1CH2 * C * DI-H5 (LV) = 
STSE1CH2 . C . PART:!. < LV ) 
STSE1CH2.C.H2 (I..V) = 
STSE1CH2.C.H25 (LV) = 
STBE1CH2.C.H3 (LV) = 
STSE 1 CH2 » C » H4 1 (LV) » 
STSE1CH2.C.HT4 (LV) = 
STSE1CH2 * C * H45 (LV) ~ 
STSE1CH2 * C . H49 (LV) = 


~ 3 . 983789 0 625 0 0 0 0 0 0 E+ 0 () 1 

~ 2 . 2677734375 0 0 0 0 0 0 E+ 0 0 1 

:l . 59328 1 25 0 0 0 0 0 0 0 0 E+ 0 0 2 
6 . 5 0 5 0 78 1 25 0 0 0 0 0 0 0 E+ 0 (! 1 
1 . 6 :l. 9 1 T 8254 39 45 3 :l. 2E -■ 0 02 
1.21 375 0 0 0 0 0 0 0 0 0 0 0 E+ 0 0 2 
1.9060 9 37 5 0 0 0000 0 0E+00 2 
l . 6840 1 567220 68787E+0 02 
5 . 54281250 0 0 0 0 0 0 0 0 E+ 0 02 
3 .9496875 0 00 00 00 00 E + 0 0 2 
3.800 6250 0 0 0 0 0 0 0 0 0 E+ 0 0 2 
3.1503125000000000 E + 0 0 2 


DUAL PROCESSOR RESULTS 

STSE2CH2 . C . DHQTHT ( LV) ™ 3 . 98378906250 0 0 0 0 OEM) 0 1 

STSE2CI 12 . C . DHQTH5 ( LV ) = 2 . 2677734375 0 00 00 0 EH 0 0 I 

STSE2CH2.C.DH41 (LV) == 1 . 593281250 00 0 0 0 0 OEM) 02 

STSE2CH2 . C . DH45 (LV) = 6. 50507812500 00 00 0E+0 0 I. 

STSE2CH2 . C , FART1 (LV) = 1 .6191482543945312E-002 

STSE2CH2.P.H2 (LV) ~ 1 , 2137500 00 00 0 0 00 OEM) 02 

STSE2CH2.P.H25 (LV) == 1 ,9060937500 00 0 0 0 0E+002 

STSE2CH2 . P . H3 ( LV ) « 2 , 6S40156722068787E+0 02 

STSE2CH2 . C . I IT 1 ( LV ) = 5 . 5T28 1 25 0 00 0 0 0 0 0 0 E+ 0 0 2 

STSE2CH2 . C . HTT ( LV ) = 3 . 9496875 0 0 0 0 0 0 0 0 0 EM) 02 

STBE2CI 12 . C . HT5 ( LV ) = 3 . 80 06250 0 0 0 0 0 0 0 0 0E+0 02 

STSE2CH2.C.H49 (LV) = 3 . 15031250 00 00 00 00E+002 



TABLE III. - COMPARISON OF SINSLE-PROCESSOR, DUAL-PROCESSOR, 
AND QUAD-PROCESSOR STEADY-STATE RESULTS 


SINGLE PROCESSOR RESULTS 

STSE1CH2.C.THT(VU (LV> “ T , 1 07 i I218750 0 OOOO 0E-«-0 0 0 
STSE 1.CH2 « C , THTA^S <LV) = 2,90 198630 0 051. 21 23E+ 0 00 

STSE1CH2.C. TORQC < L'J ) = 2 . 0830 1.I9650573730E+0 02 

STSE 1 CH2 * C * TORCH 1 <LV) * 2 . 0728629680T082T2E+0 02 

STSE1CH2 *C • TQRCTOS <LV> ~ 1 ,9078153 i U9 i »9^629E+002 

STSE1.CH2 ♦ C * T25 <LU> = 8. 1262500000000000E+002 

STSE 1CH2 • C . T25Q2 <LV> = 1 . 60 01.5B691T062500E+00 0 

STSE1CH2.C.T3C < I...U ) - 1 . 1.3T9691.92S0T8B28E+003 


DUAL PROCESSOR RESULTS 

STSE2CH2.C.THTAT1 <LV) = -T , 1.07T2. 1.875 00 0000 0E+0 00 
STSE2CH2 *C ♦ TITTAT5 <LV) == 2, 9^1.986300 0512123E+Q 00 

STSE2CH2 » P . TORQC <LV) = 2 . 0830 1/19650573730EM)02 

STSE2CH2 . C » TORQT1. <LU) == 2 . 072862968T-TT82T2E+0 02 

STSE2CH2.C.T0RCM5 (L.V) == 1 .9073153- < I19T9 / 1629E+002 

STSE2CH2 ♦ P ♦ T2S (L.U> = 8. 1262500000000000E+ 002 

STSE2CH2 * F : ' > T25Q2 <LV> = 1 ,60015869i'T06250GE+000 

STSE2CH2 . P » T3C < \.V > ~ 1 , 13'196919250T882BE+003 


QUAD PROCESSOR RESULTS 

BTSE4CH3 . C » THTA'Tl (LU) = 1 07-T218750000000E+000 

STSETCH3,C.THTAT5 (LV) == 2 , 9 / » 1 9863 0 0 0 5 1 2 1 23E-* 0 00 

STSETCH2.P. TORQC <LU) = 2. 08301T9650573730E+002 

STSETCH3 * P , TORGMi <LV> = 2 . 072862968'l‘ f H82T2E+0 02 

STSETCH3 . C . TORQ'OS (LV> = 1 , 90781.530190906298+0 02 

STSETCH2 ♦ C . T25 (LAD == 8. 1.26250 00 00 0000 00E+ 002 

STSETCH2 tCt T25Q2 <LV> => 1. , 60 01.5B691-T062500E+00 0 

STSETCH2.C.T3C <LU> = 1. . 1.3^9691. 9250'T8828E+003 
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Figure 1. - Real-time multiprocessor simulator (RTMPS) hardware 
configuration. 


CONSTANT t 

KDHB = S1/15fC 18210 
KRQV3 = Sl/OvC .9717*13; 

5WA31 * S1/5fC 27 .9233? 

PSTD » S1/^fC 14.6963? 

TSTD = SI /l 0 r C 518 • 673* 

SPST3 = Sl/ltC .95631 
SNDES = Sl/9 rC 447 .3; 

SO 025 « S1/-3»L .00253; 

S84 = S2/9fC8.-T1; 

SH3T3 ■ S1/-2fC. 2^9631 
S308 = S1/12fE30B. 3> 

S3298 = Sl/2 » C 3 ♦ 298 3 » 

S0O56 ~ S2/"» fE .08563 f 
STH41 = S1/-8»C • 00183263; 

KMCTRB - S1/~3fE .087631 
KV41 » S1/3»C6.173» 

STRG41 « SI / 13 fE 7^2.9 *353 * 

S039 « S1/-^fC .0393; 

S115 * S2/1 fill .153 f 
S2^0 * SI./— 2 fE .2^0 3 J 
S239 «* Sl/-2rC.2393; 

STQRCIC = Sl/13fC7 / l29»353; 

SNGDT =» Sl/8 fE 21*1 « 59 3» 

S9623 = 81/0 fC .962331 

XW2CB « Sl/^ f^C 0.0f3*0f^ *9Sf 12. 0 3; 

NM2CB = I1f2C2fG3; 

ZB2 « S1/-1 f^C ♦ 01057 f .01057 ». 009 Of. 00903. 
XW2C = S1/'»t'IC3.0f8.3f10.0f12.03; 

NW2C « I1f2E2fB31 

ZWXQ2 = S1/-3f4E .0B51f ,0846. .0815f .077931 


Figure 2. - Portion of RTMPL constant 
declaration section. 









VARIABLE 


DEL2 « Sl/l»C/*957953» 
RTTH2 » S1/1 pC/. 989573$ 

WS3 - S2/-2fC/« 16314 3? 

T3 - S2/11fC/1164.13? 

P3 = S2/9fC/184«543? 

F*S3 - S2/10 # C/176 « 42 3? 
PS3CJ2 = S1/5pC/12.5323? 
T3Q2 - S1/2fC/2«29193? 

T3C = S2/11 #C/1 164» 1 3? 
xxx DERIVATIVE T3 ***J 
T3DT « 52/10 f2C/0 ♦ 3? 

NG « S2/16fC/41516»3? 

NGC ■ S2/16fC/41953. 3? 

PC NGC = S1/7fC/93.0563? 
WA2C = SI /5 # C /B ♦ 2345 3 ? 

WA2 «= S2/4fC/7.97143? 

B1 ® S1/-1 #C /0 » 3? 

02 " S1/-1fC/.0093f 
WB25 = 52/3 fC/. 07174223? 
WA3 « S2/4fC/7.G??63? 

WXQ2 = S1/-3fC/. 0046061 3? 
WB3 » S2/4 f C / • 69435 3 ? 

Ml = S2/9 fC/173.143? 

TERM1 = S2/5fC/11 .403? 

WA31 » S1/4fC/ 7. 2051 3? 
xx* DEFCIVATIVE WS3 ***? 
WS3DT - S2/4 f2C/0 ♦ 3? 

H3 - S2/9fC/282« 153# 

FAR41 = S1/-4»C/. 01804283? 
H41 «= Sl/10 fC/599«883» 

Figure 3. - Portion of RTMPL 
variable declaration section. 


EXEC: STFEEXECC03# 

X** ENGINE DYNAMICS x**? 

DEL2 * P2/PSTD » 

RTTH2 « SORT < T2/TSTD > ? 

P3 = KRGV3XWS3XT3J 
F'SS ® SFST3xP3$ 

PS3Q2 » PS3/P2? 

T3Q2 = FUN1CXPF<C1fNPRC1fZTRCfPS3Q2 3? 

T3C * T3Q2XT2# 

NGC - NG/RTTH2 ? 

FCNGC ■ ngc/sndeb? 

WA2C « MAFCXPRCfYFNGCfNPRCfZW2CfPS3Q2fF > CNGC 3 
WA2 « ( W A2.C/RTTH2 ) xDEL2 ? 

01 ® FUNICXPNGCfNPNGCfZBIfPCNGCD? 

82 = FUNIC XW2CEi» NW2 CBfZB2f WA2C 3# 

NO 25 « <Bl+B2)xWA2? 

WA3 « WA2-WE525 ? 

WXQ2 - F'UNl C XW2C f NW2C t ZWXG2 » WA2C 3 ? 

WB3 » < WXQ2+S0 0 25 ) *W A2 ? 

WA31 * SORT <SWA31xWS3x(F‘3-P41> > ? 

H3 = SH3T3XT3-S84? 

FAF<41 » 5TFE1CH1 »P ♦ WF/WA31 ? 

H41 * <H3+KDHBxFAR41>/(Sl+FAR41>$ 

T41 » S3298XH41+S308? 

THTA41 =» STH41XT41+S0356? 

W41 - KWGTRB*<P41/SGRT (THTA41 ) ) ? 

F-R45Q1 « P45/P41? 

DHQTH4 = FUN1CXF'F<!GT fNF'RGT » ZDHGTQfF‘R45Q1 3? 
DH41 - DHQTH4*THTA41 ? 

T0RG41 «= <<STRQ4lxDH41>/NG>xW41? 

T25G2 « 51 15+S039*F'S3Q2 ? 

Figure 4. - Portion of equations defining 
simulation model. 






P41/P41 design 



Figure 7. - Compressor discharge temperature 
versus time. Single processor. 



Figure 8. - Gas generator turbine inlet pres 1 
sure versus time. Single processor. 



*** PROCESSOR A ***; 


pr^sqi ® p*s/p*i j 
*** VERIFY P3 ***> 

*** VERIFY WS3 ***> 

WA31 « SQF\T<BWA31*STSE2CH2.P*WS31;1*< STSE2CH2.P t F'3-F’^l ) > 
FAR41 * STSE2CH1 .P»WF/WA31 i 
*** VERIFY H3 ***> 

H4i = <STSE2CH2,P4H3+K[>HE:*FAF^1)/<S1+FAR^1)*» 

T41 » S3290*H^ 1 +S308 » 

THTA41 = 5TFM1 *141+50856; 

W41 ■ KWGTRB*<P41/SORT<THTA41>>J 
DHcrrm - funicxprgt » nf'rgt » zdhgtq » pr^scii i » 

DH11 - DHdTH4*THTA4U 


*** FRECESSOR D ***? 

P3 « KRQV3*WS3*T3J 
H3 b SH3T3*T3— S84 » 

PS3 » SPST3*P3 J 
PS3Q2 => PS3/P2J 
RTTH2 » SGRT<T2/TSTD> * 

NGC = NG/RTTH2 1 
PCNGC = NGC/SNDES » 

WA2C = MAF'C XFf<C , YPNGC , NPRC , 7.W2C » PS3Q2 v F’CNGC 1 i 

DEL2 * P2/PSTD t 

WA2 = < WA2C/RTTH2 ) *DEL2 » 

*** VERIFY WXQ2 ***» 

WB3 == < STQE2CH2 • C « WXQ2+S 0 025) *W A2 » 

T25G2 = S115+S039*PS3Q2; 


Figure 9. - Portion of dual processor equation split. 



(b) Dual processor. 

Figure 10. - Gas generator turbine speed 
versus time. 



Time, sec 
(b) Dual processor. 

Figure 11. - Compressor discharge tempera- 
ture versus time. 



(b) Dual processor. 

Figure 12. - Gas generator turbine inlet 
pressure versus time. 




STMT 

TIME 


"CAN "CAN 
START" END" 


218 

DE1.2 =» F'2/PSTD; 

0 

218 

770 

RTTH2 * SORT < T2/TSTD ) ♦ 

0 

770 

214 

WF « WFPH/SSEC; 

0 

214 

246 

P3 = KRQV3*WS3*T3? 

0 

246 

122 

PS3 = SPST3XP3S 

246 

368 

204 

PS3Q2 » PS3/P2I 

368 

572 

590 

T3G2 = FUNIC XF’RCl rNF*RCl r ZTRC»PS3Q2J » 

572 

1170 

132 

T3C » T3G2*T2> 

1170 

1302 

434 

NGC = NG/RTTH2 # 

770 

1204 

190 

PCNGC = NGC/SNDES$ 

1204 

1402 

2136 

WA2C « MAF'C XF’FiC * YF'NGC r NPRC » ZW2C r PS3Q2 r PCNGC !3 i 

1402 

3533 

292 

WA2 - < WA2C/RTTH2 > *DEL2 i 

3538 

3830 

590 

E:i * FUNIC XPNGC » NPNGC » ZB1 r PCNGC 3* 

1402 

2000 

610 

BZ ■ FUNIC XF-J2CB t NW2CB » ZB2 1 WA2C 3 » 

3538 

4148 

122 

WB25 * <B1+B2)*WA2J 

4148 

4270 

30 

WA3 = WA2-WB25 * 

4270 

4300 

598 

WXC12 = FUNIC XW2C » NW2C * ZWXQ2 r WA2C 3 » 

3538 

4136 

130 

WI33 = < k!XQ2+S0025)*WA2» 

4136 

4266 

97 * 

WA31 = GQRT<SWA31*WS3*<P3-P4D) } 

246 

1220 

142 

H3 - SH3T3*T3— S84 * 

0 

142 

224 

FAR41 » WF/WA315 

1220 

1444 

346 

H41 = <H3+KDHB*FAR41>/(S1+FAF^41)J 

1444 

1790 

122 

T41 = S3298*H41+S3D8J 

1790 

1912 

122 

THTA41 ■ STH41*T41+S0856» 

1912 

2034 

838 

W41 - KWGTRB*<P41/SQRT<THTA41>); 

2034 

2872 

230 

PR45G1 = P45/P41? 

0 

230 

598 

DHGTH4 = FUNIC XPRGT rNPRGT »ZDHGTQ»F‘F<45D1 3* 

230 

828 

118 

DH41 - DHQTH4*THTA4i; 

2034 

2152 

390 

TORG41 = <<STRG41*DH41)/NG)*W41» 

2872 

3262 

134 

T25Q2 = SI 15+S039*F‘S3Q2 » 

572 

706 

118 

T25 = T 2502*12* 

706 

824 

114 

H25 = S240*T25* 

824 

938 

126 

H2 ~ S239*T2* 

0 

126 

594 

TORQC = STOFifOC* ( ( H3*WA3-H2*WA2+H25*WtJ25 > /NG > * 

430 0 

4894 

54 

H44 - H41-OH41* 

2152 

2206 

114 

H45 « S9623*M44 * 

2206 

2320 

122 

T45 = S3537*H45+S1745» 

2320 

2442 

230 

PR49G5 = P49/P45* 

0 

230 

598 

W45C = FUNICXF'RF'T rNFI^PT *ZW45C*F'R49Q53* 

230 

828 

122 

THTA45 - STH45*T45>S0856; 

2442 

2564 

852 

W45 - <F’45/S0RT (THTA45) >*W45C* 

2564 

3416 

610 

DH0TH5 = FUNIC XPRPT »NF : ‘RF‘T * ZDHPTQ t PR49Q5 3 » 

230 

840 

118 

DH45 = DHQTH5*THT A45 * 

2564 

2682 

390 

T0RQ45 ■ <<STRG45*DH45)/NP>*W45J 

3416 

3806 

42 

H49 =* H45-DH45* 

2682 

2724 

578 

NGDT = SNGDT*(TOF<Q41-TOF;OC) * 

4894 

5472 

560 

NFDT = SNFOT* ( T0RQ45— TORQLD ) * 

3806 

4366 

338 

P41DT = (KU41*T41 >* < WA31-W41+WF ) * 

2872 

3210 

494 

P45DT » <KV45*T45)*(W41~W45+S7826*WXQ2*WA2)f 

4136 

4630 

502 

T3DT = ST3LG* (T3C-T3) » 

1302 

1804 

130 

WS3DT = WA3-WB3-WA31 * 

4300 

4430 

204 

NG » ADAMSC NG * NGDT » DELT AT » SFTNG 1 * 

5472 

5676 

204 

NP » ADAMSC NPfNPDT*DELTAT*SFTNP 3* 

4366 

4570 

196 

P41 - ADAMSC P41 »F : *41DT »DELTAT *SFTP41 3* 

3210 

3406 

198 

P45 = ADAMSC P45,P45DT»DELTAT*SFTP45 3* 

4630 

4828 

184 

T3 ■ ADAMSC T3 *T3DT* DELTAT »SFTT3 3? 

1804 

1988 

206 

WS3 - ADAMSC WS3*WS3DT * DELTAT *SFTWS33» 

4430 

4636 


Figure 13. - "CAN START" and "CAN END" times (in compute cycles) for 
simulation equations. 



*** PROCESSOR A ***? 


*** engine: dynamics ***? 

P3 => KR0V3*WS3*T3? 

PS 3 * SP8T3*P3? 

PS302 = PS3/P2 ? 

M3 » SH3T3*T3-S8^ f 
**# XFER M3 ***# 

T25Q2 = S115'»S039*PS3Q2? 

TZ5 « T25Q2*T2 ? 

H25 = 82-10*125? 

T3Q2 * FUN1CXPRC1,NPRC1,ZTRC»P83Q23J 
T3C = T3Q2XT2; 

*** VERIFY PCNGC ***? 

B1 * FUN IE XPNGC* NPNGC ? 2B1 » STBE^CHZ *P »PCNGC 3 » 
*** UPDATE DERIVATIVE ***? 

TERM7 = T3C—T3 ? 

T3DT --- ST3LG*TERM7? 

*** UPDATE INTEGRATOR **#? 

T3 =» ADAMSC T3 * T3DT r DELT AT » SFTT3 3 ? 

DEL.2 •* P2/PSTD ? 

at**: WAIT 2 *#*? 

*** VERIFY HA2C ***? 

*** VERIFY RTTH2 ***» 

WA2 = ( STSE'LCHZ ♦ P « WA2C/8TSE4CH2 « P « RTTH2 ) #DEL2 ? 
*#* XFER WA2 ***? 

*** REVERIFY WA2C ***? 

WXQ2 » FUNIC XW2C t NW2C » ZWXQ2 » 8TSE4CM2 . P ♦ WA2C 3 ? 
*** XFER WXQ2 ***? 

MB3 a (MXQ2-<-S0025>xMA2l 
*** UPDATE DERIVATIVE ***? 

*** VERIFY WA3 *** ? 

*** VERIFY MA31 ***? 

WS3DT ** STSE4CH2 * P . W A3-WB3-STSE4CM3 ♦ C . WA31 ? 
x*K UPDATE INTEGRATOR ***? 

MS 3 a ADAMSC W33 , W33DT , DELT AT f SFTMS3 3 ? 

Figure 14. - Quad processor distribution of 
simulation equations. 


*** PROCESSOR B ***? 

*** ENGINE DYNAMICS (CRITICAL PATH) ***? 

RTTH2 •- SQRT(T2/TSTD>? 

NGC = NG/RTTH2? 

PCNGC « NGC/SNDES? 

*** VERIFY PS3Q2 *** ? 

WA2C « MAPC XPRC r YPNGC , NPRC » ZW2C » STSE4CH2 . C . PS3Q2 ? PCNGC 3 
B2 “ FUNIC XW2CE: » NW2CB * ZB2 1 WA2C 3 ? 

*** VERIFY B1 ***? 

*** VERIFY WA2 ***? 

WB25 “ < STSE4CH2 * C . B1+B2 > XSTSE4CH2 . C ♦ WA2 ? 

*** REVERIFY WA2 ***? 

WAS « ST8F.4CH2 . C . W A2-WB25 ? 

*** VERIFY H3 ***? 

**# VERIFY H2 ***? 

*** REVERIFY WA2 *** ? 

TERM 2 a STBE/LCH2 ♦ C . H3*WA3-STSE-1CH3 . P ♦ H2*STSE4CH2 . C . MA2 ? 
w*w UFRTFY H? 11 ! wwwl 

TORQC a STORQCx < C TERM2+STSE4CH2 . C ♦ H25*WB25 ) /NG > ? 

*** UPDATE DERIVATIVE ***? 

*** VERIFY TORCHl ***? 

TERM3 = STSE4CH3.P* TORCH 1-TOftQCI 

NGDT = SNGDTXTERM3I 

*** UPDATE INTEGRATOR ***? 

NG a ADAMSC NG r NGDT t DELTAT* SFTNG 3? 


Figure 14. - Continued, 



*** PROCESSOR C ***; 

*** ENGINE DYNAMICS ***; 

*** VERIFY WS3 **#» 

*** VERIFY T3 ***; 

P3 = KRQV3KSTSE4CH2«C'NS3*lxSTSE4CH2.C.T3*i; 

*** VERIFY P41 ***» 

TERM1 = P3-STSE^CH3.P«F^l*li 
*** REVERIFY WS3 ***; 

WA31 = SaFa<SWA31*5TE;E‘TCH2»C.WS3l;l*TERMl> ; 

*** XFER WA31 ***» 

*** VERIFY WF ***♦ 

FART1 « STSE^CHl »P. WF/WA31 » 

*** VERIFY H3 ***; 

H41 = <STSE4CH2.C«H3+KDHB*FAR41)/<Sl+FAR4i>? 

T41 = S32?8*H-T1+S308 » 

THTA'll = STmi*T^l+S0856; 

*** VERIFY DHQTFW ***5 

DHT1 « STSE^CH3.p4DHQTm*THTA'U* 

HW .=> mi-DH^l? 
m5 = 59623*FI 'Hi 
T45 = S3537*m5+S17^5; 

THTA^S = STFH5*TT5+S0856i 
*** VERIFY P45 ***i 
*** VERIFY W^SC ***} 

W'IS = < STSE^CH3 1 P * P^St 1 /SORT ( TMT A'IS ) >*STSE4CH3.P»WT5Ci 
*** VERIFY DHQTH5 ***♦ 

DEWS « STSE^ICHS . F* « DHQTH5*TH1 A^5 i 

TOF4CH5 = < <STR0 i 1S*DEH5>/NP>*VH5; 

m? = mS-DFHSi 

*** UF'DATE DERIVATIVE ***i 

*** VERIFY TORQLD ***i 

TERMT » T0RQT5-STSETCH1 . P. TORQLD » 

NPDT «= SNPDTxTERM4$ 

*** UPDATE INTEGRATOR ***i 

NP « ADAMSC NF : ' * NPDT » DELT AT » SFTNP 1 i 


Figure 14. - Continued. 


#** PROCESSOR D ***» 

*** ENGINE DYNAMICS ***i 
PR4SQ1 = P45/P41J 

DHQTW = FUNIC XF‘F<GT » NF’RGT * ZDHGTQ »PR^5Q1 h t 
PRWK3 = P49/FH5i 

W4SC = FUNIC XPRPT » NF’RPT * ZFH5C » F‘FH9Q5 1 i 
DHQTH5 = FUN 1C XPRPT rNPRPTfZDHPTQfPRT‘?Q5i; 

H2 “ S239*T2i 
x** XFER H2 ***» 

*** WAIT 8^ #**; 

*** VERIFY THTAT1 ***i 

WT1 = KWGTRE:* (P-Tl/SQRT (STSE^ICH3. C* THTA'Fl ) ) ; 

*** VERIFY DM1 ***» 

*** VERIFY NG ***? 

TORCM1 = < <STRtMl*STSE^CH3*C»DFHl )/STSE^CH2«F'*NG$J. )*FM1 » 

*** XFER TORCH 1 ***i 
*** UPDATE DERIVATIVE ***» 

*** VERIFY WA31 ***i 
TERMS = STSE4CFI3.C»WA31~W'lli 
*** VERIFY T^l ***; 

F’TIDT * <KV^l*STSE^CH3.C.TTl)w(TERM5+STSE^CHl«P,WF>; 

*** UPDATE INTEGRATOR ***i 

F’^l = ADAMSC P^ 1 » FH 1 DT » DELT AT » SFTF’^ 1 H J 

*** UPDATE DERIVATIVE ***i 

*** VERIFY VMS ***i 

TERM6 = W^l-STSE4CFI3.C.VH5i 

*** VERIFY T45 ***» 

*** VERIFY WXQ2 ***i 
*** VERIFY WA2 ***» 

P'TSDT = < KV / 1S*STSETCH3 * C ♦ T T5 ) * ( TERM6+ 

S7826*STSETCH2 . C . WXQ2*STSE'FCH2 . C . WA2 ) 

*** UPDATE INTEGRATOR ***J 

r-45 rn ADAMSC P'15 1 F‘^5DT » DELT AT » SFTF‘^5 3 » 


Figure 14. - Concluded. 
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Figure 15. - Gas generator turbine speed 
versus time. Quad processor. 



Figure 16. - Compressor discharge temperature 
versus time. Quad processor. 



Figure 17. - Gas generator turbine inlet 
pressure versus time. Quad processor. 
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